ETSITS123 048V4.5.0 



(2005-06) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 
Security mechanisms for the (U)SIM application toolkit; 

Stage 2 
(3GPP TS 23.048 version 4.5.0 Release 4) 



33i^ 



GS 




® 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 





3GPP TS 23.048 version 4.5.0 Release 4 1 ETSI TS 1 23 048 V4.5.0 (2005-06) 



Reference 



RTS/TSGC-0623048V450 
Keywords 



GSM, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2005. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade Marks of ETSI registered for the benefit of its Members. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 23.048 version 4.5.0 Release 4 2 ETSI TS 1 23 048 V4.5.0 (2005-06) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 23.048 version 4.5.0 Release 4 3 ETSI TS 1 23 048 V4.5.0 (2005-06) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 9 

4 Overview of Security System 10 

5 Generalised Secured Packet structure 11 

5.1 Command Packet structure 11 

5.1.1 Coding of the SPI 12 

5.1.2 Coding of the Klc 13 

5.1.3 Coding of the KID 13 

5.1.4 Counter Management 14 

5.2 Response Packet structure 15 

6 Implementation for SMS-PP 16 

6.1 Structure of the UDH of the Security Header in a Short Message Point to Point 16 

6.2 A Command Packet contained in a Single Short Message Point to Point 17 

6.3 A Command Packet contained in Concatenated Short Messages Point to Point 17 

6.4 Structure of the Response Packet 19 

7 Implementation for SMS-CB 20 

7.1 Structure of the CBS page in the SMS-CB Message 20 

7.2 A Command Packet contained in a SMS-CB message 20 

7.3 Structure of the Response Packet for a SMS-CB Message 21 

8 Standardised (U)SIM toolkit commands for Remote File Management 21 

8.1 Behaviour of the Remote File Management Application 21 

8.2 Coding of the commands 22 

8.2.1 SIM Input Commands 22 

8.2.2 SIM Output Commands 22 

8.2.3 USIM input commands 22 

8.2.4 USIM output commands 23 

8.3 SIM specific behaviour for Response Packets (Using SMS-PP) 23 

8.4 USIM specific behaviour for Response Packets (Using SMS-PP) 24 

9 Open Platform commands for Remote Applet Management 24 

9.1 Remote Applet Management Application behaviour 24 

9.1.1 Package Loading 24 

9.1.2 Applet Installation 25 

9.1.3 Package Removal 25 

9.1.4 Applet Removal 25 

9.1.5 Applet Locking / Unlocking 25 

9.1.6 Applet Parameters Retrieval 25 

9.2 Commands coding 25 

9.2.1 Input Commands 25 

9.2.2 Output Commands 26 

9.3 Response Packets 26 

9.3.1 SIM Response Packets 26 

9.3.2 USIM Response Packets 26 

Annex A (normative): Applet Management Commands for TS 43.019 compliant cards 27 



£75/ 



3GPP TS 23.048 version 4.5.0 Release 4 4 ETSI TS 1 23 048 V4.5.0 (2005-06) 

A.l Commands Description 27 

A.1.1 DELETE 27 

A.1.2 GET DATA 27 

A. 1.2.1 Menu Parameters 27 

A. 1.2. 2 Card Resources Information 28 

A.l. 3 GET STATUS 28 

A.1.4 INSTALL 28 

A.1.4.1 Install (Load) 28 

A.1.4.2 Install (Install) 29 

A. 1.4.2.1 Toolkit Applet Specific Parameters 30 

A. 1.4.2.2 Memory space 30 

A. 1.4.2. 3 Access domain 30 

A. 1.4.2. 3.1 Access Domain Parameter 30 

A. 1.4.2. 3. 2 APDU access mechanism 31 

A.l. 4.2.4 Priority level of the Toolkit applet 32 

A.1.5 LOAD 32 

A.1.6 SET STATUS 33 

A.1.7 PUT KEY 33 

A.2 Security Management for Applet Management using APDUs 33 

A.2.1 Selection of Card Manager and Security Domain 33 

A.2.2 Mutual authentication 33 

A.2.3 APDU's DAP Computation 33 

Annex B (informative): Change History 34 

History 35 



£75/ 



3GPP TS 23.048 version 4.5.0 Release 4 5 ETSI TS 1 23 048 V4.5.0 (2005-06) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the structure of the Secured Packets in a general format and in implementations using 
Short Message Service Point to Point (SMS-PP) and Short Message Service Cell Broadcast (SMS-CB). 

Furthermore, the coding is specified for a set of common application commands within the secured packets. This set is a 
subset of commands specified in TS 51.011 [5] and allows remote management of files on the UICC in conjunction 
with SMS and the Data Download to UICC feature of TS 3 1 . 1 1 1 . 

For UICCs based on TS 43.019 [15], the set of commands used in the remote applet management is defined in the 
present document. This is based on the Open Platform card management specification [14]. For UICCs based on other 
technologies, other loading mechanisms may be used. 

The present document is applicable to the exchange of secured packets between an entity in a 3G or GSM PLMN and 
an entity in the UICC. 

Secured Packets contain application messages to which certain mechanisms according to TS 22.048 have been applied. 
Application messages are commands or data exchanged between an application resident in or behind the 3G or GSM 
PLMN and on the UICC. The Sending/Receiving Entity in the 3G or GSM PLMN and the UICC are responsible for 
applying the security mechanisms to the application messages and thus turning them into Secured Packets. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Application Layer: layer above the Transport Layer on which the Application Messages are exchanged between the 
Sending and Receiving Applications 

Application Message: package of commands or data sent from the Sending Application to the Receiving Application, 
or vice versa, independently of the transport mechanism 

NOTE 1 : An Application Message is transformed with respect to a chosen Transport Layer and chosen level of 
security into one or more secured packets. 

Command Header: Security Header of a Command Packet. It includes all fields except the Secured Data 

Command Packet: Secured Packet transmitted by the Sending Entity to the Receiving Entity, containing a secured 
Application Message 

Counter: mechanism or data field used for keeping track of a message sequence 

NOTE 2: This could be realised as a sequence oriented or time stamp derived value, maintaining a level of 
synchronisation between the Sending Entity and the Receiving Entity. 

Cryptographic Checksum: string of bits derived from some secret information, (e.g. a secret key), part or all of the 
Application Message, and possible further information (e.g. part of the Security Header) 

NOTE 3: The secret key is known to the Sending Entity and to the Receiving Entity. The Cryptographic Checksum 
is often referred to as Message Authentication Code. 

DES: standard cryptographic algorithm specified as DEA in ISO 8731-1 [9]. 

Digital Signature: string of bits derived from some secret information, (e.g. a secret key), the complete Application 
Message, and possible further information (e.g. part of the Security Header) 

NOTE 4: The secret information is known only to the Sending Entity. Although the authenticity of the Digital 

Signature can be proved by the Receiving Entity, the Receiving Entity is not able to reproduce the Digital 
Signature without knowledge of the secret information owned by the Sending Entity. 

Message Identifier: two-octet field used to identify the source and type of the message 

Page Parameter: single octet field used to represent the CBS page number in the sequence and the total number of 
pages in the SMS-CB message 

Receiving Application: entity to which the Application Message is destined 
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Receiving Entity: entity where the Secured Packet is received (e.g. SMS-SC, UICC, USSD entry point, or dedicated 
(U)SIM Toolkit Server) and where the security mechanisms are utilised 

NOTE 5: The Receiving Entity processes the Secured Packets. 

Redundancy Check: string of bits derived from the Application Message and possible further information for the 
purpose of detecting accidental changes to the message, without the use of any secret information 

Response Header: Security Header of a Response Packet 

Response Packet: Secured Packet transmitted by the Receiving Entity to the Sending Entity, containing a secured 
response and possibly application data 

Secured Data: this field contains the Secured Application Message and possibly padding octets 

Secured Packet: information flow on top of which the level of required security has been applied 

NOTE 6: An Application Message is transformed with respect to a chosen Transport Layer and chosen level of 
security into one or more Secured Packets. 

Security Header: that part of the Secured Packet which consists of all security information (e.g. counter, key 
identification, indication of security level, checksum or Digital Signature) 

Sender Identification: this is the simple verification of the identity of the Sending Entity by the Receiving Entity 
comparing the sender identity with an apriori stored identity of the sender at the Receiving Entity 

Sending Application: entity generating an Application Message to be sent 

Sending Entity: this is the entity from which the Secured Packet originates (e.g. SMS-SC, UICC, USSD entry point, or 
dedicated (U)SIM Toolkit Server) and where the security mechanisms are invoked 

NOTE 7: The Sending Entity generates the Secured Packets to be sent. 
Serial Number: two octet field which identifies a particular message 

NOTE 8: It is linked to the Message Identifier and is altered every time the message is changed. 

Short Message: information that may be conveyed by means of the SMS Service as defined in TS 23.040. 

Status Code: this is an indication that a message has been received (correctly or incorrectly, indicating reason for 
failure) 

Transport Layer: this is the layer responsible for transporting Secured Packets through the 3G and GSM network. 

NOTE 9: The transport layer implements one or more transport mechanisms, (e.g. SMS or USSD). 

Unsecured Acknowledgement: this is a Status Code included in a response message 
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3.2 



Abbreviations 



For the purpose of the present document, the following abbreviations apply: 

CBC Cipher Block Chaining 

CBS Cell Broadcast Service 

CC Cryptographic Checksum 

CNTR Counter 

CHI Command Header Identifier 

CHL Command Header Length 

CPI Command Packet Identifier 

CPL Command Packet Length 

DAP Data Authentication Pattern 

DBS Data Encryption Standard 

DCS Data Coding Scheme 

DS Digital Signature 

ECB Electronic codebook 

lEI Information Element Identifier 

lEIDL Information Element Identifier Data Length 

lED Information Element Data 

KIc Key and algorithm Identifier for ciphering 

KID Key and algorithm Identifier for RC/CC/DS 

KIK Key Identifier for protecting KIc and KID 

MID Message IDentifier 

MO-SMS Mobile Originated Short Message 

MT-SMS Mobile Terminated Short Message 

OP Open Platform 

PCNTR Padding Counter 

PLMN Public Land Mobile Network 

PoR Proof of Receipt 

PP Page Parameter 

RA Receiving Application 

RC Redundancy Check 

RE Receiving Entity 

RHI Response Header Identifier 

RHL Response Header Length 

RPI Response Packet Identifier 

RPL Response Packet Length 

SA Sending Application 

SE Sending Entity 

SIM Subscriber Identity Module 

SM Short Message 

SMS Short Message Service 

SMS-PP Short Message Service - Point to Point 

SMS-CB Short Message Service - Cell Broadcast 

SMS-SC Short Message Service - Service Centre 

SN Serial Number 

SPI Security Parameters Indication 

TAR Toolkit Application Reference 

TLV Tag - Length - Value (data structure) 

UDH User Data Header 

UDHI User Data Header Indicator 

UDHL User Data Header Length 

UDL User Data Length 

USIM Universal Subscriber Identity Module 

USSD Unstructured Supplementary Services Data 
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Overview of Security System 



An overview of the secure communication related to the (U)SIM Application Toolkit together with the required security 
mechanisms is given in TS 22.048, (see figure 1). 
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Figure 1 : System Overview 

The Sending Application prepares an Application Message and forwards it to the Sending Entity, with an indication of 
the security to be applied to the message. 

The Sending Entity prepends a Security Header (the Command Header) to the Application Message. It then applies the 
requested security to part of the Command Header and all of the Application Message, including any padding octets. 
The resulting structure is here referred to as the (Secured) Command Packet. 

Under normal circumstances the Receiving Entity receives the Command Packet and unpacks it according to the 
security parameters indicated in the Command Header. The Receiving Entity subsequently forwards the Application 
Message to the Receiving Application indicating to the Receiving Application the security that was applied. The 
interface between the Sending Application and Sending Entity and the interface between the Receiving Entity and 
Receiving Application are proprietary and therefore outside the scope of the present document. 

If so indicated in the Command Header, the Receiving Entity shall create a (Secured) Response Packet. The Response 
Packet consists of a Security Header (the Response Header) and optionally, application specific data supplied by the 
Receiving Application. Both the Response Header and the application specific data are secured using the security 
mechanisms indicated in the received Command Packet. The Response Packet will be returned to the Sending Entity, 
subject to constraints in the transport layer, (e.g. timing). 

Although there is no direct acknowledgement to an SMS-CB message in TS 24.012 [12], the Sending Application may 
have requested a response. In this case a (Secured) Response Packet could be sent using a different bearer by the 
Receiving Application. 
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In some circumstances a security related error may be detected at the Receiving Entity. In such circumstances the 
Receiving Entity shall react according to the following rules: 

1) nothing shall be forwarded to the Receiving Application, i.e. no part of the Application Message, and no 
indication of the error. 

2) if the Sending Entity does not request a response (in the Command Header) the Receiving Entity discards the 
Command Packet and no further action is taken. 

3) if the Sending Entity does request a response and the Receiving Entity can unambiguously determine what has 
caused the error, the Receiving Entity shall create a Response Packet indicating the error cause. This Response 
Packet shall be secured according to the security indicated in the received Command Packet. 

4) if the Sending Entity does request a response and the Receiving Entity cannot determine what has caused the 
error, the Receiving Entity shall send a Response Packet indicating that an unidentified error has been detected. 
This Response Packet is sent without any security being applied. 

5) If the Receiving Entity receives an unrecognisable Command Header (e.g. an inconsistency in the Command 
Header), the Command Packet shall be discarded and no further action taken. 



5 Generalised Secured Packet structure 

Command and Response Packets have the same overall structure consisting of a variable length security header within a 
variable length shell. To model this, use is made of a double TLV -tag, length, value- structure. 



5.1 



Command Packet structure 



The Command Header precedes the Secured Data in the Command Packet, and is of variable length. 
The Command Packet shall be structured according to table 1 . 

Table 1 : Structure of the Command Packet 



Element 


Length 


Comment 


Command Packet Identifier (CPI) 


1 octet 


Identifies that this data block is the secured Command Packet. 


Command Pacl<et Length (CPL) 


variable 


This shall indicate the number of octets from and including the 
Command Header Identifier to the end of the Secured Data, 
including any padding octets required for ciphering. 


Command Header Identifier (CHI) 


1 octet 


Identifies the Command Header. 


Command Header Length (CHL) 


variable 


This shall indicate the number of octets from and including the 
SPI to the end of the RC/CC/DS. 


Security Parameter Indicator (SPI) 


2 octets 


see detailed coding in clause 5.1 .1 . 


Ciphering Key Identifier (KIc) 


1 octet 


Key and algorithm Identifier for ciphering. 


Key Identifier (KID) 


1 octet 


Key and algorithm Identifier for RC/CC/DS. 


Tooll<it Application Reference 
(TAR) 


3 octets 


Coding is application dependent. 


Counter (CNTR) 


5 octets 


Replay detection and Sequence Integrity counter. 


Padding counter (PCNTR) 


1 octet 


This indicates the number of padding octets used for ciphering at 
the end of the secured data. 


Redundancy Check (RC), 
Cryptographic Checksum (CC) or 
Digital Signature (DS) 


variable 


Length depends on the algorithm. A typical value is 8 octets if 
used, and for a DS could be 48 or more octets; the minimum 
should be 4 octets. 


Secured Data 


variable 


Contains the Secured Application IVIessage and possibly padding 
octets used for ciphering. 



Unless indicated otherwise, the CPL and the CHL shall be coded according to ISO/IEC 7816-6 [8]. 
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Table 2: Linear Representation of Command Packet 



CPI 


CPL 


CHI 


CHL 


SPI 


KIc 


KID 


TAR 


CNTR 


PCNTR 


RC/CC/DS 


Secured 
Data with 
Padding 


















note 1 


note 1 


Note1 


note 1 




note 3 




note 3 


note 2 


note 2 


note 2 


note 2 


note 2 


note 2 




note 2 


NOTE 1 : These fields are included in the data to be ciphered if ciphering is indicated in the Security Header. 
NOTE 2: These fields are included in the calculation of the RC/CC/DS. 

NOTE 3: Part or all of these fields may also be included in the calculation of the RC/CC/DS, depending on 
implementation (e.g. SIVIS). 



If ciphering is indicated, first the RC/CC/DS shall be calculated as indicated in Note 2, and then ciphering shall be 
applied, as indicated in Note 1 . 

If the SPI indicates that a specific field is unused, the Sending Entity shall set the contents of this field to zero, and the 
Receiving Entity shall ignore the contents. 

If the SPI indicates that no RC, CC or DS is present in the Command Header, the RC/CC/DS field shall be of zero 
length. 

If the Padding Counter content is zero, this shall indicate no padding octets, or no padding is necessary. 

5.1.1 Coding of the SPI 

The SPI is coded as below. 
First Octet: 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



00: No RC, CC or DS 

01 : Redundancy Check 

10: Cryptographic Checksum 

11: Digital Signature 

: No Ciphering 

1 : Ciphering 



00: No counter available (note 1) 

01: Counter available; no replay or sequence 

checking (note 2) 
10: Process if and only if counter value is higher 

than the value in the RE (note 3) 
11: Process if and only if counter value is one 

higher than the value in the RE (note 4) 

Reserved (set to zero and ignored by RE) 



NOTE 1: In this case the counter field is present in the message. 

NOTE 2: In this case the counter value is used for information purposes only, (e.g. date or time stamp). If the 
Command Packet was successfully unpacked, the counter value can be forwarded from the Receiving 
Entity to the Receiving Application. This depends on proprietary implementations and happens in an 
application dependent way. 

NOTE 3: The counter value is compared with the counter value of the last received Command Packet. This is 

tolerant to failures on the transport level (i.e. losses of Command Packets). A possible scenario is a global 
update. 

NOTE 4: This provides strict control in addition to security indicated in note 3. 
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Second Octet: 



b8 b7 b6 b5 b4 b3 b2 bl 



00 

01 
10 

11 

00 
01 
10 

11 



No PoR reply to the Sending Entity (SE) 

PoR required to be sent to the SE 

PoR required only when an error has occured 

Reserved 

No security applied to PoR response to SE 
PoR response with simple RC applied to it 
PoR response with CC applied to it 
PoR response with DS applied to it 



: PoR response shall not be ciphered 

1 : PoR response shall be ciphered 

For SMS only 

: PoR response shall be sent using 

SMS-DELIVER-REPORT 

1 : PoR response shall be sent using SMS-SUBMIT 

Reserved (set to zero and ignored by RE) 



5.1.2 Coding of the KIc 

The KIc is coded as below. 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



00 
01 
10 

11 



Algorithm known implicitly by both entities 

DES 

Reserved 

proprietary Implementations 



00: DES in CBC mode 

01 : Triple DES in outer-CBC mode using two 

different keys 
10: Triple DES in outer-CBC mode using three 

different keys 
11: DES in ECB mode 

indication of Keys to be used 

(keys implicitly agreed between both entities) 



DES is the algorithm specified as DEA in ISO 8731-1 [9]. DES in CBC mode is described in ISO/IEC 101 16 [10]. 
Triple DES in outer-CBC mode is described in section 15.2 of [17]. DES in ECB mode is described in 
ISO/IEC 10116 [10]. 

The initial chaining value for CBC modes shall be zero. 

If the indication of the key to be used refers to an Open Platform key set version number, the algorithm to be used with 
the key shall be the algorithm associated with the key (as described in the Open Platform specification [14]). 

5.1.3 Coding of the KID 

The KID is coded as below. 
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b8 b7 b 



b5 b4 b3 b2 bl 



00 
01 
10 

11 



Algorithm known implicitly by both entities 

DES 

Reserved 

proprietary Implementations 



00: DES in CBC mode 

01: Triple DES in outer-CBC mode using two 

different keys 
10: Triple DES in outer-CBC mode using three 

different keys 
11 : Reserved 

indication of Keys to be used 

(keys implicitly agreed between both entities) 



DES is the algorithm specified as DEA in ISO 8731-1 [9]. DES in CBC mode is described in ISO/IEC 101 16 [10]. 
Triple DES in outer-CBC mode is described in section 15.2 of [17]. 

The initial chaining value for CBC modes shall be zero. If padding is required, the padding octets shall be coded 
hexadecimal '00'. These octets shall not be included in the secured data. 

If the indication of the key to be used refers to an Open Platform key set version number, the algorithm to be used with 
the key shall be the algorithm associated with the key (as described in the Open Platform specification [14]). 

5.1 .4 Counter Management 

If in the first SPI byte b4b5=00 (No counter available) the counter field shall be ignored by the RE and the RE shall not 
update the counter. 

If b5 of the first SPI byte is equal to 1 then the following rules shall apply to counter management, with the goal of 
preventing replay and synchronisation attacks: 

The SE sets the counter value. It shall only be incremented. 

The RE shall update the counter to its next value upon receipt of a Command Packet after the corresponding 
security checks (i.e. RC/CC/DS and CNTR verification) have been passed successfully. 

The next counter value is the one received in the incoming message. 

- When the counter value reaches its maximum value the counter is blocked. 

If there is more than one SE, care has to be taken to ensure that the counter values remain synchronised between the 
SE's to what the RE is expecting, irrespective of the transport mechanism employed. 

The level of security is indicated via the proprietary interface between the Sending/Receiving Application and 
Sending/Receiving Entity. Application designers should be aware that if the Sending Application requests "No 
RC/CC/DS" or "Redundancy Check" and "No Counter Available" from the SE, no security is applied to the Application 
Message and therefore there is an increased threat of malicious attack. 
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5.2 Response Packet structure 



Table 3: Structure of the Response Packet 



Element 


Length 


Comment 


Response Packet Identifier (RPi) 


1 octet 


Identifies a Response Packet. 


Response Pacl<et Length (RPL) 


variable 


Indicates the number of octets from and including RHI to the end 
of Additional Response data, including any padding octets 
required for ciphering. 


Response Header Identifier (RHI) 


1 octet 


Identifies the Response Header. 


Response Header Length (RHL) 


variable 


Indicates the number of octets from and including TAR to the end 
of RC/CC/DS. 


Tooll<it Application Reference 
(TAR) 


3 octets 


This shall be a copy of the contents of the TAR in the Command 
Packet. 


Counter (CNTR) 


5 octets 


This shall be a copy of the contents of the CNTR in the Command 
Packet. 


Padding counter (PCNTR) 


1 octet 


This indicates the number of padding octets used for ciphering at 
the end of the Additional Response Data. 


Response Status Code Octet 


1 octet 


Codings defined in Table 5. 


Redundancy Checl< (RC), 
Cryptographic Checksum (CC) or 
Digital Signature (DS) 


variable 


Length depending on the algorithm indicated in the Command 
Header in the incoming message. A typical value is 4 to 8 octets, 
or zero if no RC/CC/DS is requested. 


Additional Response Data 


variable 


Optional Application Specific Response Data, including possible 
padding octets. 



Unless indicated otherwise, the RPL and RHL shall be coded according to ISO/IEC 7816-6 [8]. 



Table 4: Linear Representation of Response Packet 



RPI 


RPL 


RHI 


RHL 


TAR 


CNTR 


PCNTR 


Status 
Code 


RC/CC/DS 


Additional 

Response 

Data with 

padding 












note 1 


note 1 


note 1 


note 1 


note 1 




note 3 




note 3 


note 2 


note 2 


note 2 


note 2 




note 2 


NOTE 1 : If ciphering is indicated in the Command Packet SPI then these fields shall be ciphered. 
NOTE 2: These fields shall be included in the calculation of the RC/CC/DS. 

NOTE 3: Part or all of these fields may also be included in the calculation of the RC/CC/DS, depending on 
implementation (e.g. SMS). 



If ciphering is indicated, first the RC/CC/DS shall be calculated as indicated in Note 2, and then ciphering shall be 
applied, as indicated in note 1 . 

If the SPI indicates that a specific field is unused, than its contents shall be set to zero, and ignored by the recipient of 
the Response Packet. 

If the SPI in the Command Packet indicates that no RC, CC or DS is present in the Command Header, this field shall be 
of zero length. 

If the Padding Counter content is zero, this shall indicate no padding octets are present, or no padding is necessary. 
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Table 5: Response Status Codes 



Status Code 
(hexadecimal) 


Meaning 


'00' 


PoROK. 


'01' 


RC/CC/DS failed. 


'02' 


CNTR low. 


'03' 


CNTR high. 


'04' 


CNTR Blocked 


'05' 


Ciphering error. 


'06' 


Unidentified security error. This code is for the case where the Receiving Entity cannot correctly 
interpret the Command Header and the Response Packet is sent unciphered with no RC/CC/DS. 


'07' 


Insufficient memory to process incoming message. 


'08' 


This status code "more time" should be used if the Receiving Entity/Application needs more time 
to process the Command Packet due to timing constraints. In this case a later Response Packet 
should be returned to the Sending Entity once processing has been completed. 


'09' 


TAR Unknown 


'OA' - 'FF' 


Reserved for future use. 



6 Implementation for SMS-PP 

6.1 Structure of the UDH of the Security Header in a Short 
IVIessage Point to Point 

The coding of the SMS-DELIVER, SMS-SUBMIT, SMS -DELI VER-REPORT or SMS-SUBMIT-REPORT header 
shall indicate that the data is binary (8 bit), and not 7 bit or 16 bit. In order to invoke the UDH functionality of relevant 
SMS element, the UDHI bit shall be set as defined in TS 23.040 [3]. However, in the case of a Response Packet 
originating from the UICC, due to the inability of the UICC to indicate to a ME that the UDHI bit should be set, the 
Response Packet SMS will not have the UDHI bit set, and the Sending Entity shall treat the Response Packet as if the 
UDHI bit was set. 



Octets 



Octets 



UDL 



UDHL 



lEIa 



\/ 



lEIDLa 



lEDa 



lEIb 



lEIn 



\/ 



lEDLn 



lEDn 



SM (8 bit data) 



< 

Length Indicator 



Total number of Octets 



7\" 



^ 



Octet Boundary 



<- 



Total number of Octets 



Length Indicator 



7^ 



^ 



Figure 2: Structure of User Data Header in the Short Message Point to Point 

The generalised structure of the UDH in the Short Message element is shown in figure 2, which is contained in the User 
Data part of the Short Message element. The Command Packet and the Response Packet are partially mapped into this 
UDH structure. 

Information Element Identifiers (lEI's) values '70 - 7F' are reserved for use in the present document. Values '70' and '71' 
are used in the present document, values '72 - 7D' are reserved, and '7E' and '7F' are for proprietary implementations. 
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Where a Response Packet is too large to be contained in a single SMS-DELIVER-REPORT or SMS-SUB MIT- 
REPORT TP element, a Response Packet containing the Status Code "more time" should be returned to the SE using 
the SMS-REPORT element, followed by a complete Response Packet, contained in a SMS-DELIVER or SMS- 
SUBMIT element, which may be concatenated. 

6.2 A Command Packet contained in a Single Short IVIessage 
Point to Point 

The relationship between the Command Packet and its inclusion in the UDH structure of a single Short Message with 
no other UDH elements is indicated in table 6. 

Table 6: Relationship of Command Packet in UDH for single Short Message Point to Point 



SMS specific 
elements 


Generalised Command 

Packet Elements (Refer 

to table 1) 


Comments 


UDL 




Indicates the length of the entire SM. 


UDHL 


='02' 


The first octet of the content or User Data part of the Short Message 
itself. Length of the total User Data Header, in this case, includes the 
length of lEIa + lEIDLa + lEDa (see figure 2), and is '02' in this case. 


lEIa 


CPI= '70' 


Identifies this element of the UDH as the Command Packet Identifier. 
This value is reserved in TS 23.040 [3]. 


lEIDLa 


='00' 


Length of this object, in this case the length of lEDa, which is zero, 
indicating that lEDa is a null field.. 


lEDa 




Null field. 


SM (8 bit data) 


Length of Command 
Packet (2 octets){Note) 


Length of the Command Packet (CPL), coded over 2 octets, and shall 
not be coded according to ISO/IEC 7816-6 [8]. 


Command Header 
Identifier 


(CHI) Null field. 


Length of the Command 
Header 


Length of the Command Header (CHL), coded over one octet, and shall 
not be coded according to ISO/IEC 7816-6 [8]. 


SPI to RC/CC/DS in the 
Command Header 


The remainder of the Command Header. 


Secured Data 


Application Message, including possible padding octets. 



NOTE: Whilst not absolutely necessary in this particular instance, this field is necessary for the case where 
concatenated Short Message is employed (see clause 6.3). 

lEIa identifies the Command Packet and indicates that the first portion of the SM contains the Command Packet Length, 
the Command Header length followed by the remainder of the Command Header: the Secured Data follows on 
immediately as the remainder of the SM element. The UDHL field indicates the length of the lEIa and lEIDLa octets 
only ('02' in this case). 

It is recognised that most checksum algorithms require input data in modulo 8 length. In order to achieve a modulo 8 
length of the data before the RC/CC/DS field in the Command Header the Length of the Command Packet and the 
Length of the Command Header shall be included in the calculation of RC/CC/DS if used. These fields shall not be 
ciphered. 

6.3 A Command Packet contained in Concatenated Short 
IVIessages Point to Point 

If a Command Packet is longer than 140 octets (including the Command Header), it shall be concatenated according to 
TS 23.040 [3]. In this case, the entire Command Packet including the Command Header shall be assembled, and then 
separated into its component concatenated parts. The first Short Message shall contain the concatenation User Data 
Header and the Command Packet Identifier in the UDH in no particular order. Subsequent Short Messages shall contain 
only the concatenation User Data Header. The concatenation Header contains a Reference number that will allow the 
Receiving Entity to link individual Short Messages together to re-assemble the original Command Packet before 
unpacking the Command Packet. 
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The relationship between the Command Packet and its inclusion in the structure of the first concatenated Short Message 
is indicated in table 7; the ordering of the various elements of the UDH is not important. 

Table 7: Relationship of Command Packet in UDH for concatenated Short Message Point to Point 



SMS specific 
elements 


Generalised Command 

Packet Elements (Refer 

to table 1) 


Comments 


UDL 




Indicates tine lengtti of tine entire SM 


UDHL 


='07' 


Tine first octet of ttie content or User Data part of the Stiort IVIessage 
itself. Lengtti of the total User Data Header, in this case, includes the 
length of lEIa + lEIDLa + lEDa + lEIb + lEIDLb + lEDb (see figure 2), 
which is '07' in this case. 


lEIa 


'00', indicating 
concatenated siiort 
message 


identifies this Header as a concatenation control header defined in TS 
23.040 [3]. 


lEIDLa 


Lengtii of Concatenation 
lieader 


length of the concatenation control header (= 3). 


lEDa 


3 octets containing data 
concerned witti 
concatenation 


These octets contain the reference number, sequence number and total 
number of messages in the sequence, as defined in TS 23.040 [3]. 


lEIb 


CPI= '70' 


Identifies this element of the UDH as the Command Packet Identifier. 


lEIDLb 


='00' 


Length of this object, in this case the length of lEDb alone, which is 
zero, indicating that lEDb is a null field. 


lEDb 




Null field. 


SM (8 bit data) 


Lengtii of Command 
Pacl<et (2 octets) 


Length of the Command Pacl<et (CPL), coded over 2 octets, and shall 
not be coded according to ISO/IEC 7816-6 [8]. 


Command Header 
Identifier 


(CHI) Null field. 


Lengtii of the Command 
Header 


Length of the Command Header (CHL), coded over one octet, and shall 
not be coded according to ISO/IEC 7816-6 [8]. 


SPI to RC/CC/DS in Xhe 
Command Header 


The remainder of the Command Header. 


Secured Data (part) 


Contains the first portion of the Secured Data. The remaining Secured 
Data will be contained in subsequent concatenated short messages. 



In the case where the Command Packet requires to be concatenated, then in table 7, lEIa identifies the concatenation 
control element of the Short Message, and is repeated in each subsequent Short Message in the concatenated series. In 
the first Short Message alone, in this example, lEIb identifies the Command Packet, which indicates that the first 
portion of the content of the Short Message contains the Command Header, which is followed immediately by the 
secured data as the SM part in table 7. In the first Short Message, the UDHL field contains the length of the 
concatenation control and the Command Packet Identifier, whereas in subsequent Short Message's in the concatenated 
series, the UDHL contains the length of the concatenation control only, as there is no subsequent Command Header. 

If the data is ciphered, then it is ciphered as described above, before being broken down into individual concatenated 
elements. The concatenation control portion of the UDH in each SM shall not be ciphered. 

In order to achieve a modulo 8 length of the data before the RC/CC/DS field in the Command Header, the Length of the 
Command Packet and the Length of the Command Header shall be included in the calculation of RC/CC/DS if used. 
These fields shall not be ciphered. 

An example illustrating the relationship between a Command Packet split over a sequence of three Short Messages is 
shown below. 
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CH 


Secured data 


Padding 






CC1 


CH 





CC2 



CCS 



First SMS in sequence 



Second SMS 



Third and final SMS 



where CCn = Concatenation Control (1 ,2,3) 
CH = Command Header 



Figure 3: Example of command split using concatenated point to point SMS 

6.4 Structure of the Response Packet 

The Response Packet is as follows. This message is generated by the Receiving Entity and possibly includes some data 
supplied by the Receiving Application, and returned to the Sending Entity/Sending Application. In the case where the 
Receiving Entity is the UICC, depending on bit 6 of the second octet of the SPI, this Response Packet is generated on 
the UICC, either: 

- retrieved by the ME from the UICC, and included in the User-Data part of the SMS-DELIVER-REPORT 
returned to the network; or 

retrieved by the ME from the UICC using the Send Short Message proactive command. 
Table 8: Relationship of Response Packet in UDH 



SMS-REPORT 
specific 
elements 


Generalised Response 

Packet Elements (Refer 

to table 3) 


Comments 


UDL 




Indicates the length of the entire SMS 


UDHL 


='02' 


The first octet of the content of the SMS itself. Length of the total User 
Data Header, in this case, includes the length of lEIa + lEIDLa + lEDa. 


lEIa 


RPI='71' 


Identifies this element of the UDH as the Response Packet Identifier. 
This value is reserved in TS 23.040 [3]. 


lEIDLa 


='00' 


Length of this object, in this case the length of lEDa alone, which is 
zero, indicating that lEDa is a null field. 


lEDa 




Null field. 


SM (8 bit data) 


Length of Response 
Packet 


Length of the Response Packet (RPL), coded over 2 octets, and shall 
not be coded according to ISO/IEC 7816-6 [8]. (see note) 


Response Header 
Identifier 


(RHI) Null field. 


Length of the Response 
Header 


Length of the Response Header (RHL), coded over one octet, and shall 
not be coded according to ISO/IEC 7816-6 [8]. 


TAR to RC/CC/DS 
elements in the 
Response Header 


The remainder of the Response Header. 


Secured Data 


Additional Response Data (optional), including padding octets. 



NOTE: This field is not absolutely necessary but is placed here to maintain compatibility with the structure of the 
Command Packet when included in a SMS-SUBMIT or SMS-DELIVER. 

In order to achieve a modulo 8 length of the data before the RC/CC/DS field in the Response Header, the Length of the 
Response Packet, the Length of the Response Header and the three preceding octets (UDHL, lEIa and lEIDLa in the 
above table) shall be included in the calculation of RC/CC/DS if used. These fields shall not be ciphered. 

The structure of an SMS-DELIVER/SUBMIT-REPORT User Data object is very similar to that of the SMS-SUBMIT 
or SMS-DELIVER, see TS 23.040 [3]. 
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7 



Implementation for SMS-CB 



This chapter is appUcable to a SMS-CB message in a GSM network only. 

7.1 Structure of the CBS page in the SMS-CB Message 

The CBS page sent to the MS by the BTS is a fixed block of 88 octets as coded in TS 24.012 [12]. The 88 octets of CBS 
information consist of a 6-octet header and 82 user octets. 

The 6-octet header is used to indicate the message content as defined in TS 23.041 [11]. This information is required to 
be transmitted unsecured in order for the ME to handle the message in the correct manner (e.g. interpretation of the 
DCS). 

The content of the message shall be secured as defined in this clause. 

A range of values has been reserved in TS 23.041 [11] to indicate SMS-CB Data Download messages that are secured 
and unsecured. A subset of these values is used to indicate the Command Packet for CBS messages. This range is from 
(hexadecimal) '1080' to '109F' and is included in the structure of the Command Packet as illustrated in table 9. 

7.2 A Command Packet contained in a SMS-CB message 

The relationship between the Command Packet and its inclusion in the SMS-CB message structure is indicated in 
table 9. 

Table 9: Relationship of Command Packet in the first CBS page of an SMS-CB message 



SMS-CB 
specific 
elements 


Generalised Command 

Packet Elements (Refer 

to Table 1) 


Comments 


SN 




Refer to TS 23.041 [11]. Coded on 2 octets containing the ID of a 
particular message. 


MID 


CPI='1080'to'109F' 


Coded on 2 octets containing the source and type of the message. The 
Command Packet Identifier range is reserved in TS 23.041 [11]. (see 
note) 


DCS 




Refer to TS 23.041 [11]. Coded on 1 octet containing the alphabet 
coding and language as defined in TS 23.038 [13]. 


PP 




Refer to TS 23.041 [11]. Coded on 1 octet to indicate the page number 
and total number of pages. 


Content of 
Message 


GPL 


Length of the Command Packet, coded over 2 octets, and shall not be 
coded according to ISO/IEC 7816-6 [8]. 


CHI 


The Command Header Identifier. Null field. 


CHL 


This shall indicate the number of octets from and including the SPI to 
the end of the RC/CC/DS field. Binary coded over 1 octet. 


SPI to RC/CC/DS in the 
Command Header 


The remainder of the Command Header. 


Secured Data 


Application Message, including possible padding octets. 



NOTE: Generally, the CPI is coded on 1 octet, as specified in table 1. However, the CPI for the SMS-CB message 
is coded on 2 octets as the values reserved in TS 23.041 [11] to identify the Command Packet are MID 
values which are coded on 2 octets. 

It is recognised that most checksum algorithms require input data in modulo 8 length. In order to achieve a modulo 8 
length of the data before the RC/CC/DS field in the Command Header the Length of the Command Packet and the 
Length of the Command Header shall be included in the calculation of RC/CC/DS if used. These fields shall not be 
ciphered. 

Securing of the complete CBS message is achieved outside the GSM specifications by the Sending Entity. The Secured 
CBS message is formatted in accordance with the GSM specifications and transmitted to the MS as CBS pages. The 
CBS pages are received by the ME and sent directly to the UICC, by analysing the MID value. The UICC shall then 
reassemble, decrypt and process the message. 
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An example illustrating the relationship between a Command Packet split over a sequence of three SMS-CB pages is 
shown below. 



CH I Secured Data I Padding 



/ \ 



Header 


CH 





Header 





Header 





First CBS page in the sequence 



Second CBS page 



Third and final CBS page 



In the above figure, Header = 6 Octet header as defined in GSM 03.41 (i.e. SN, MID, DCS and PP) and 
CH = Command Header 

Figure 4: Example of command split using concatenated CB SMS 

7.3 Structure of the Response Packet for a SMS-CB Message 

As there is no response mechanism defined for SMS-CB, there is no defined structure for the (Secured) Response 
Packet. However, if a (Secured) Response Packet is sent via another bearer the structure shall be defined by the 
Receiving Application. 



8 



Standardised (U)SIM toolkit commands for Remote 
File Management 



There are two elements to Remote File Management on the UICC; the first is the behaviour of the UICC resident 
Toolkit Application which performs the Remote File Management, and the second is the command structure in the SIM 
Data Download message, see TS 31.111 [6]. Access conditions for the 3G and GSM files as seen by the UICC resident 
application, are not standardised. These are under the control of the application designer, in co-operation with the 
Network Operator or Service Provider owning the UICC. These access conditions may be dependent on the level of 
security applied to the Data Download to UICC message (e.g. SMS-PP). 

8.1 Behaviour of the Remote File Management Application 

1 . The parameter(s) in the Data Download Message to UICC is either a single command, or a list of commands, 
which shall be processed sequentially. 

2. The application shall take parameters from the Data Download Message to UICC and shall act upon the 3G 
and/or GSM files according to these parameters. 

3. A Command "session" is defined as starting upon receipt of the parameter/command list, and ends when the 
parameter list in the Data Download Message to UICC is completed, or when an error is detected which shall 
halt further processing of the command list. 

4. At the beginning and end of a Command "session" the logical state, (e.g. file pointers) of the UICC as seen from 
the ME shall not be changed to an extent sufficient to disrupt the behaviour of the ME. If changes in the logical 
state have occurred that the ME needs to be aware of, the application on the UICC may issue a REFRESH 
command according to TS 31.111 [6]. However, this is application dependent and therefore out of scope of the 
present document. 
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8.2 Coding of the commands 



A command string may contain a single command or a sequence of commands. Each command is coded according to 
the generalised structure defined below; each element other than the Data field is a single octet; see TS 51.011 [5]. 



Class byte 
(CLA) 


Instruction 
code (INS) 


PI 


P2 


P3 


Data 



If a command has P3='00', then the UICC shall send back all available response parameters/data. 

Administrative commands have not yet been defined, and thus, remain proprietary to UICC manufacturers for the 
present. 



8.2.1 SIM Input Commands 

The standardised commands are listed in table 10. The commands are as defined in TS 51.01 1 [5], except that the 
SELECT command is extended from the one in TS 51.01 1 [5] to include "SELECT by path" as defined in 
ISO/IEC 7816-4 [7]. 

Table 10: Input Commands 



Operational command 



SELECT 

UPDATE BINARY 

UPDATE RECORD 

SEEK 

INCREASE 

VERIFY CHV 

CHANGE CHV 

DISABLE CHV 

ENABLE CHV 

UNBLOCK CHV 

INVALIDATE 
REHABILITATE 



8.2.2 SIM Output Commands 

The commands listed in table 11 are defined in TS 51.011 [5]. These commands shall only occur once in a command 
string and, if present, shall be the last command in the string. The Response Data shall be placed in the Additional 
Response Data element of the Response Packet. If SMS is being used, these should result in the generation of a single 
SM by the UICC. 

Table 11 : Output commands 



Operational command 



READ BINARY 
READ RECORD 
GET RESPONSE 



8.2.3 USIM input commands 

The standardised commands are listed in table 12. The commands are as defined in TS 31.101[16]. 
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Table 12: USIM Input Commands 



Operational command 



SELECT 

UPDATE BINARY 

UPDATE RECORD 

SEARCH RECORD 

INCREASE 

VERIFY PIN 

CHANGE PIN 

DISABLE PIN 

ENABLE PIN 

UNBLOCK PIN 

DEACTIVATE FILE 

ACTIVATE FILE 



The SELECT command shall not include the selection by DF name corresponding to Pl="04" in the Command 
Parameters of SELECT (see TS 31.101[16]). 

8.2.4 USIM output commands 

The standardised commands are listed in table 13. The commands are as defined in TS 3 1.101 [16]. 

These commands shall only occur once in a command string and, if present, shall be the last command in the string. The 
Response Data shall be placed in the Additional Response Data element of the Response Packet. 



Table 13: USIM Output Commands 



Operational command 



READ BINARY 
READ RECORD 
GET RESPONSE 



8.3 SIM specific behaviour for Response Packets (Using 
SMS-PP) 

Table 14 summarises the behaviour of the SIM's RE/RA with regard to PoR. 

Table 14: SIM specific behaviour 



PoR 


successful case 


Unsuccessful cases (see table 5) 


No 


'90 00' or '91 XX', null RP-ACK 


'90 00' or '91 XX', null RP-ACK 


Yes 


'9F XX' (PoR OK, status code '00'). 


'9E XX' (security error of some kind). 



NOTE: 



in the case where no proof of Receipt is required by the sending entity, it is however permissible for the 
SIM to send back data using '9F XX' in the successful case or '9E XX' in the unsuccessful case. 



If the SIM responds with the '90 00' or '91 XX' code, then there is no User Data to be included in an SMS-DELIVER- 
REPORT; the ME sends a "null" RP-ACK, with no User Data attached. 

In the case of a '9F XX' or '9E XX' response from the SIM, 'XX' indicates the length of the response data to be obtained 
from the SIM using a later GET RESPONSE command. The response obtained from the SIM is the complete Response 
Packet to be included in the User Data part of the SMS-DELIVER-REPORT which will be returned to the Sending 
Entity as the TP part of the RP-ACK in the '9F XX' case, or as the TP part of the RP -ERROR in the '9E XX' case. In the 
case of a '9E XX' response from the SIM, the value of the TP-FCS element of the RP -ERROR shall be 'SIM data 
download error'. Because the SIM is unable to indicate to the ME that the TP-UDHI bit is to be set, the Sending Entity 
receiving the Response Packet shall expect the UDH structure in any event. See TS 24.01 1 [4] for more detail of the 
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structure of the RP-ACK and RP-ERROR protocol element, and TS 23.040 [3] for more detail of the SMS-DELIVER- 
REPORT structure. 

If a proof of Receipt is required by the sending entity, the Additional Response Data sent by the Remote File 
Management Application shall be formatted according to table 15: 

Table 15: Format of additional response data 



Length 


Name 


1 


Number of commands executed within the command 
script (see note) 


2 


Last executed command status word 


X 


Last executed command response data if available 
(i.e., if the last command was an outgoing command) 


NOTE: This field shall be set to '01 ' if one command was 
executed within the command script, '02' if two 
commands were executed, etc... 



8.4 



USIM specific behaviour for Response Packets (Using 
SIVIS-PP) 



To be defined. 



9 Open Platform commands for Remote Applet 

Management 

Remote Applet Management on a UICC card includes the ability to load, install, and remove applets. This management 
is under the responsibility of the Network Operator or Service Provider owning the UICC. The described procedure is 
mandatory for TS 43.019 compliant cards. Other technologies may either use this procedure or use their own 
mechanisms. The concept of embedding APDUs in a short message is as defined in clause 7 "Remote File 
management" in the present document. 

9.1 Remote Applet Management Application behaviour 
9.1.1 Package Loading 

The Package Loading process allows the Network Operator or Service Provider to load new packages onto the UICC. 
The Network Operator or Service Provider manages the loading of a package through a loading session with the card. 

A loading session consists of the sequence of commands as described in figure 5. 



INSTALL(load) 




> 


i 




LOAD(multiple 
intermediate) 


-^ 








> 


i 




LOAD(final) 





Figure 5: Loading session sequence of commands 
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Depending on the applet size, several SMS might be use for the package loading. 
The commands are defined in Annex A. 

9.1.2 Applet Installation 

The Applet Installation process allows the Network Operator or Service Provider to install a new application onto the 
UICC . The installation may only be performed if the corresponding package has already been loaded onto the card. The 
Applet Installation is performed using the INSTALL(install) command, as defined in annex A. 

9.1.3 Package Removal 

The Package Removal process is performed using the DELETE command, as defined in annex A. The Package removal 
procedure shall be performed by the UICC as defined below: 

1 . If non removed applications installed from this package remain, the card shall reject the removal with the 
corresponding status error code. 

2. If the package is referred by other package(s), the card shall reject the removal with the corresponding status 
error code. 

9.1.4 Applet Removal 

The Applet Removal process shall be performed using the DELETE command, as defined in Annex A. The UICC shall 
remove the components that make up the applet. 

9.1 .5 Applet Locking / Unlocking 

The Applet locking (and unlocking) procedure allows the Network Operator or Service Provider to disable (and enable) 
an applet using the SET STATUS command as defined in Annex A. When an applet is locked, it shall not be possible to 
be triggered or selected, and all of its menu entries will be disabled (i.e. removed from the SET UP MENU command). 

9.1 .6 Applet Parameters Retrieval 

The Applet Parameters Retrieval procedure allows the Network Operator or Service Provider to remotely request the 
parameters of an applet. This procedure is performed using the GET DATA command as defined in annex A. 

9.2 Commands coding 

Commands are coded as for the Remote File Management procedure, each command is coded as an APDU. 
The messages for the Card Manager shall have a TAR value set to '000000' in hexadecimal. 

9.2.1 Input Commands 

The following table extends table 10 defined in clause 8.2. L 

Table 16: Applet Management input commands 



Operational command 



DELETE 

SET STATUS 

INSTALL 

LOAD 
PUT KEY 
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9.2.2 Output Commands 

The following table extends table 1 1 defined in clause 8.2.2. 

Table 17: Applet Management output commands 



Operational command 



GET STATUS 
GET DATA 



9.3 Response Packets 

9.3.1 SIM Response Packets 

The behaviour of the SIM's RE/RA with regard to PoR is the same as the one defined for Remote File Management (see 
clause 8.3). 

9.3.2 USIM Response Packets 

To be defined. 
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Annex A (normative): 

Applet Management Commands for TS 43.019 compliant 

cards 

This annex describes the commands for Applet Management. 

A complying card shall support at least the DES CBC algorithm for cryptographic computations. 

Command status words placed in the Additional Response Data element of the Response Packet shall be coded 
according to the Open Platform specification [14]. 



A.1 Commands Description 



The minimum security applied to a Secured Packet containing Applet Management Commands shall be integrity using 
CC or DS, and in all cases, this security shall replace Data Authentication Patterns used in Open Platform commands 
for secure messaging. 

A.1.1 DELETE 

The Delete command shall be coded according to the Open Platform specification [14]. The references to DAP (Data 
Authentication Pattern) fields are not applicable for Over The Air Application Management. 

NOTE: This command may be extended in the future to allow for other type of deletion since the command data 
uses TLV structure. 

A. 1.2 GET DATA 

The Get Data command shall be coded according to the Open Platform specification [14]. The references to DAP (Data 
Authentication Pattern) fields are not applicable for Over The Air Application Management. 

The command Get Data is extended to retrieve specific card information with tag values in PI and P2. The following 
values have been defined: 

'FF IF': Menu Parameters Tag, this retrieves the menu parameters of an applet; 

'FF 20': Card Resources Tag, this retrieves information on the card resources used and available; 

'FF 21' to 'FF 7F': reserved for allocation in the present document. 

A. 1.2.1 Menu Parameters 

The following format is used to code the command data : 



Bytes 


Description 


Length 


1 


Application AID tag = '4F' 


1 


2 


Application AID length 


1 


3 - (X+2) 


Application AID 


X = 5-16 



After the successful execution of the command, the following data is returned by a GET RESPONSE command: 
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Bytes 


Description 


Length 


1 


First item position 


1 


2 


First item identifier 


1 








X-1 


Last item position 


1 


X 


Last item identifier 


1 



A. 1.2. 2 Card Resources Information 

After the successful execution of the command, the following data is returned: 



Bytes 


Description 


Length 


1-2 


Free E^PROM 


2 


3 


Number of installed applets 


1 



A.1.3 GET STATUS 

The Get Status command shall be coded according to the Open Platform specification [14]. The references to DAP 
(Data Authentication Pattern) fields are not applicable for Over The Air Application Management. 

A.1.4 INSTALL 

The Install command shall be coded according to the Open Platform specification [14]. The references to DAP (Data 
Authentication Pattern) fields are not applicable for Over The Air Application Management. 

A.1.4.1 Install (Load) 

The Load File DAP field is a Cryptographic Checksum, a Digital Signature or a Redundancy Check calculated over the 
CAP file as transmitted in the subsequent Load commands. The exact generation of this field is outside the scope of the 
present document. If a DES algorithm in CBC mode is used the initial chaining value shall be zero. If padding is 
required, the padding octets shall be coded hexadecimal '00'. 

NOTE: The Load File DAP CC, DS or RC is verified by the Card Manager. 

The Load Parameter Field of the Install (Load) command shall be coded as follows: 



Presence 


Length 


Name 


IVIandatory 


1 


Tag of System Parameters constructed field 'EF' 




1 


Length of System Parameters constructed field 




4-n 


System Parameters constructed value field. 



The System Parameters value field of the Install (Load) command shall be coded as follows: 



Presence 


Length 


Name 


Mandatory 




Tag of non volatile memory space required for package loading field: 'C6' 






Length of non volatile memory space required for package loading field 




2 


Non Volatile memory space (in bytes) required for package loading (see note) 


Optional 




Tag of non volatile memory requirements for installation field: 'C8' 






Length of non volatile memory requirements for installation 




2 


Non volatile memory required for installation in byte 


Optional 




Tag of volatile memory requirements for installation field: 'C7' 






Length of memory requirements for installation 




2 


Volatile memory required for installation in byte 


NOTE: The memory space required indicates the minimum size that shall be available onto the card to 
download the application. The UICC must reject the applet downloading if the required size is not 
available on the card. 
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A.1.4.2 Install (Install) 

Toolkit registration is only active if the toolkit applet is at the state selectable, for example if the applet is registered for 
the event Menu Selection it shall only appear in the menu if the applet is in the selectable state. 

The Install Parameter Field of the Install (Install) command shall be coded as follows: 



Presence 


Length 


Name 


Mandatory 


1 


Tag of System Parameters constructed field 'EF' 




1 


Length of System Parameters constructed field 




15-n 


System Parameters constructed value field. 


Mandatory 


1 


Tag of Applet specific parameters field: 'C9' 




1 


Length of Applet specific Parameters field 




0-n 


Applet specific Parameters 



The System Parameters value field of the Install (Install) command shall be coded as follows: 



Presence 


Length 


Name 


Mandatory 




Tag of non volatile memory requirements for installation field: 'C8' 






Length of non volatile memory requirement for installation (see A.1 .4.2.2) 




2 


Non volatile memory required for installation in byte (see A.1.4.2. 2) 


Mandatory 




Tag of volatile memory requirements for installation field: 'C7' 






Length of volatile memory requirement for installation (see A.1 .4.2.2) 




2 


Volatile memory required for installation in byte (see A.1 .4.2.2) 


Mandatory 




Tag of toolkit applet specific parameters field: 'CA' 






Length of toolkit applet specific parameters field 




6-n 


Toolkit Applet specific Parameters (see A.1 .4.2.1 ) 



Even if the length of the non volatile or volatile memory is present in the Install(Load) command, the card shall use the 
values indicated in the Install(Install) command at instantiation, should these values differ. 

The format of the install method buffer provided by the Install (Install) command shall be the one specified in the Open 
Platform Card specification [14]. 

The applet may invoke the register(b Array, bOffset, bLength) or the register() method: the applet instance shall be 
registered with the instance AID present in the Install (Install) command. 

If the register (bArray, bOffset, bLength) is invoked, the AID passed in the parameters shall be the instance AID 
provided in the install method buffer. 

If the registerO method is invoked the instance AID present in the Install(Install) command and the AID within the 
Load File, as specified in Open Platform Card specification [14], should be the same. 
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A.1 .4.2.1 Toolkit Applet Specific Parameters 

The toolkit applet specific parameters field is used to specify the ME and UICC resources the applet instance can use. 
These resources include the timers, and menu items for the Set Up Menu. The Network Operator or Service Provider 
can also defines the menu position and the menu identifier of the menus activating the applet. The following format is 
used to code the applet parameters: 



Length 


Name 


Value 


1 


Length of Access Domain field 




1-n 


Access Domain (see A. 1.4. 2. 3) 






Priority level of the Toolkit applet instance (see A.1 .4.2.4) 






IVIaximum number of timers allowed for this applet instance 






IVIaximum text length for a menu entry 






Maximum number of menu entries allowed for this applet instance 


= m 




Position of the first menu entry ('00' means last position) 


\ 




Identifier of the first menu entry ('00' means don't care) 


1 






1 = 2*m bytes 




Position of the last menu entry ('00' means last position) 


1 




Identifier of the last menu entry ('00' means don't care) 


/ 



The position of the new menu entries is an absolute position among the existing ones. 

A part of the item identifier shall be under the control of the card system and the other part under the control of the card 
issuer. Item identifiers are split in two ranges: 

[1,127] under control of the card issuer; 

[128,255] under the control of the toolkit framework. 

If the requested item identifier is already allocated, or in the range [128,255], then the card shall reject the install 
command. If the requested item identifier is '00', the card shall take the first free value in the range [128,255]. 

A.1. 4.2. 2 Memory space 

The memory space required indicates the minimum size that shall be available on the card to download the application. 
The UICC shall reject the applet downloading if the required size is not available on the card. 

A.1 .4.2.3 Access domain 

The access domain is used to specify the UICC files that may be accessed by the applet and the operations allowed on 
these files. The Access Domain field is formatted as follows: 



Length 


Name 


1 


Access Domain Parameter (ADP) (see A.1. 4.2. 3.1) 


n-1 


Access Domain Data (ADD) 



The Access Domain Data coding and length is defined for each Access Domain Parameter. 



A.1. 4.2.3.1 



Access Domain Parameter 



This parameter indicates the mechanism used to control the applet instance access to the GSM file System. 



Value 


Name 


Support 


ADD length 


'00' 


Full access to the File System 


Mandatory 





'01' 


APDU access mechanism (see A. 1.4. 2. 3. 2) 


Optional 


2 


'02' 


3GPP access mechanism (see A.1. 4.2. 3.3) 


Optional 


[To be defined] 


'03' to '7F' 


RFU 


RFU 


RFU 


'80' to 'FE' 


Proprietary mechanism 


- 


- 


'FF' 


No access to the File System 


Mandatory 
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The access rights granted to an applet and defined in the access domain parameter shall be independent fi-om the access 
rights granted at the (U)SIM/ME interface. 

If an applet with Access Domain Parameter 'FF' (i.e. No Access to the File System) tries to access a file the framework 
shall throw an exception. 

If an applet has Access Domain Parameter "00" (i.e. Full Access to the File System), all actions can be performed on a 
file except the ones with NEVER access condition. 

If the Access Domain Parameter requested is not supported, the card shall return the Status Word '6A80', incorrect 
parameters in data field, to the Install(Install) command. 



A.1. 4.2.3.2 



APDU access mechanism 



This mechanism shall be used, if supported, by the framework if the Access Domain Parameter value is '01 '. It shall use 
the Access Domain Data passed at applet instantiation to define the access conditions fulfilled while the toolkit applet is 
running. 

The APDU Access Domain Data is a bit map combination of the file access condition levels described in TS 51.011. 
When the bit is set the associated Access Condition is granted. 

The APDU Access Domain Data is coded as follows: 

Byte 1: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
































L 


ADM4 
ADM5 










ADM 6 












ADM7 














ADM8 
















ADM 9 


















ADMIO 




















RFU 



Byte 2: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
































L 


ALWays 
CHVl 










CHV2 












RFU 














ADMO 
















ADMl 


















ADM2 




















ADM3 
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EXAMPLE: 



Possible combinations of fulfilled Access Conditions are shown below: 



ADD value 


Applet access condition fulfilled 


'00 GO' 


No access 


'00 or 


ALWays 


'00 02' 


CHV1 


'00 03' 


ALWays and CHV1 


'00 04' 


CHV2 


'00 05' 


ALWays and CHV2 


'00 06' 


CHV1 and CHV2 






'00 10' 


ADMO 






'00 20' 


ADM1 






'00 22' 


ADM1 and CHV1 






'01 00' 


ADM4 






'40 00' 


ADM10 






'41 37' 


ADM10 and ADM4 and ADM1 and 
ADMO and CHV2 and CHV1 and 
ALWays 







A.1 .4.2.4 Priority level of the Toolkit applet 

The priority specifies the order of activation of an applet compared to the other applet registered to, the same event. If 
two or more applets are registered to the same event and have the same priority level, the applets are activated 
according to their installation date (i.e. the most recent applet is activated first). The following values are defined for 
priority: 

- '00' : RFU 

'01': Highest priority level 



'FF' : Lowest priority level 

A.1.5 LOAD 

The Load command shall be coded according to the Open Platform specification [14]. The references to APDU's DAP 
(Data Authentication Pattern) fields are not applicable for Over The Air Application Management. 

The load block data is created by taking successive blocks of the data from the Java Card CAP file components in the 
order described in the Java Card specification. 



CAP Component 1 




Block 1 




Block 2 


CAP Component 2 




Block 3 




Block 4 




Block 5 











Figure 6: Relationship between CAP File components and Load File Blocks 
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A.1.6 SET STATUS 

The Set Status command shall be coded according to the Open Platform specification [14]. The references to DAP 
(Data Authentication Pattern) fields are not applicable for Over The Air Application Management. 

A.1.7 PUT KEY 

The Put Key command shall be coded according to the Open Platform specification [14]. The references to DAP (Data 
Authentication Pattern) fields are not applicable for Over The Air Application Management. 

The keys which may updated by the PUT KEY command refer to the transport security keys, i.e. KID and KIc in a 
Secured Packet. In addition, a third key type is defined : KIK. This key is used to protect the PUT KEY command itself. 
Keys are structured in the following way: 





Key Set Version 


Key Set Version 1 


.... 


Key Set Version n 
(maximum 'F') 


Key Index 1 


Reserved 


Kid 




KIcn 


Key Index 2 


Reserved 


KID1 




KIDn 


Key Index 3 


Reserved 


KIK1 




KIKn 



A card may have up to 15 key set versions each containing 3 key indexes. These versions numbers represent the 
indication of keys to be used in bits 8 to 5 in the coding of KIc and KID (see clauses 5.1.2 and 5.1.3). Each key index 
represents: 

Key Index 1: KIc; 

- Key Index 2: KID; 

- Key Index 3: KIK. 

Key Sets can only be changed with the PUT KEY command once the card has been issued. New Key Sets cannot be 
created using PUT KEY command at post issuance. Key used for securing the PUT KEY command is the key index 3 
of the same key set version as the changed key. Key Set version defined in OP for the creation of keys is not relevant 
for the present document. 

A key set version number shall never be updated using the PUT KEY command. 

This command shall be executed by the Card Manager or a Security Domain depending on the TAR in the case of Over 
The Air Application Management. 



A.2 Security Management for Applet Management using 
APDUs 

A.2.1 Selection of Card Manager and Security Domain 

This topic is for further study. 

A.2. 2 Mutual authentication 

This topic is for further study. 



A.2.3 APDU's DAP Computation 



This topic is for further study. 
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